Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Ham⁄GPS/IP Folder/HAMradio TCP⁄IP/Docs/NET⁄ROM_info

Text File | 1990-07-08 | 17KB | 428 lines

                NET/ROM support in the KA9Q NET Package

                            Dan Frank, W9NK

INTRODUCTION

   The NET/ROM support for the KA9Q package serves three purposes:

    1) Existing NET/ROM networks may be used to send IP traffic.

    2) NET may be used as a NET/ROM packet switch.

    3) NET may be used to communicate with NET/ROM nodes, and its
       mailbox facility can accept connects over the NET/ROM network.


SETTING UP THE NET/ROM INTERFACE

   No physical interface is completely dedicated to net/rom, which is as
it should be.  You attach all your AX.25 interfaces, of whatever sort.
Then you attach the net/rom pseudo-interface ("attach netrom").  Then
you identify to the net/rom software those interfaces you want to allow
it to use, with the "netrom interface" command.  The format of this
command is:

    netrom interface ax0 #ipnode 192

The first argument is the name of the previously attached interface you
want to use.  The second argument is the alias of your node, to be used in
your routing broadcasts.  The alias is never used for anything else (as
you will see!).  The last number is the net/rom quality figure.  This is
used in computing the route qualities; it represents the contribution of
this interface to the overall computation.  For a 1200 baud half-duplex
connection, 192 is the right number.

   You need a netrom interface command for every interface you're going
to use with net/rom.


TRACING ON THE NET/ROM INTERFACE

   If you want to trace your NET/ROM datagrams, don't try turning
on trace mode for the "netrom" interface.  Nothing will break, but
nothing will happen.  You should trace the individual AX.25 interfaces
instead.


ROUTING BROADCASTS

   Once you have set up your interfaces, you need to set some timers.
There are two:  the nodes broadcast interval timer, and the obsolescence
timer.  These are set in seconds, like the smtp timer.  You should usually
set them to an hour.  You can set them to something different, if you want.
If your local net/rom nodes broadcast every hour, but you want to do so
every ten minutes, you can say:

    netrom nodetimer 600
    netrom obsotimer 3600

Every time the obsotimer kicks, the obsolescence counts for all non-permanent
entries are decremented by one.  When the count for an entry falls below
five, it is no longer broadcast.  When it falls to 0, it is removed.  The
count is initialized at 6.  These will eventually be settable parameters;
you can adjust them now by changing the initializers for the variables
in the source file.

   When you first come on the air, you can send out nodes broadcasts to
tell the local nodes that you are available.  Use the command:

    netrom bcnodes ax0

where ax0 is the interface on which you want to send the broadcast.  Do
this for every interface on which you want to do this.

   By default, the NET/ROM code does not broadcast the contents of your
routing table.  This is as it should be, since usually we just want to
be the endpoints of communications rather than relaying NET/ROM traffic.
If you want to be a switch station, include the command:

    netrom verbose yes

in your autoexec.

   Sometimes you can hear broadcasts from nodes that can't hear you.  If
your routing table gets filled with these unusable routes, your node will
grind to a halt.  The solution to this is node broadcast filtering, via
the netrom nodefilter command.  There is a filter list, which contains
a list of callsigns and interfaces.  Then there is a filter mode, which
indicates what to do with the list.

   If the filter mode is "none", no filtering is done.  If it is "accept",
then only broadcasts from the indicated stations on the indicated
interfaces are accepted.  If it is "reject", then all broadcasts
except those from the listed stations on the listed interfaces are
accepted.

   Because the net/rom code cannot at this time recognize unusable
routes and try alternates, I strongly recommend use of the filter
command to restrict broadcast acceptance to those nodes which you
know you can reach.


THE NET/ROM ROUTING TABLE

   The next net/rom commands are those used for maintaining
the routing table.  They fall under the "netrom route" subcommand.
"netrom add" adds a permanent entry to the routing table.  Its format
is:

    netrom route add #foo w9foo ax0 192 w9rly

This command adds an entry for w9foo, whose alias is #foo, route
quality 192, via w9rly on interface ax0.  Let's talk about what this
means.  w9foo is the *destination* node, the one to whom you want
the packets routed by the net/rom network.  w9rly is your *neighbor*,
the net/rom node to which you pass the packet to be forwarded.  Since
w9rly may appear on more than one interface (the callsign may be used
by more than one net/rom node on different bands), we specify that
we are to use ax0 to send the packet.

   With net/rom, like IP, we don't know exactly what route a packet
will take to its destination.  We only know the name of a neighbor
which has indicated a willingness to forward that packet (of course,
the neighbor may be the destination itself, but that's unlikely in
our application).  Net/rom sends the packet to the neighbor, with a
network header specifying our callsign and that of the ultimate
destination (in this case w9foo).

   We can use the netrom route add command to establish a digipeater
path to the neighbor.  For example:

    netrom route add #foo w9foo ax0 192 w9rly wd9igi

This will cause us to use wd9igi as a digipeater in establishing our
connection to the net/rom node w9rly.

   To drop the route to w9foo, you would type

    netrom route drop w9foo w9rly ax0

   To see the contents of your routing table, you may type

    netrom route

and to see the routing entries for an individual station you can type

    netrom route info <callsign>

You may not use an alias as an argument to the netrom route info command.

   I can not stress enough that "route add" and "netrom route add" are two
different commands, with different purposes.  In general, you only need a
"netrom route add" if you need to add a route to a net/rom node via a
digipeater path.  If you find yourself using this command, ask yourself,
"Why am I doing this?"  Many people do not understand that net/rom does
automatic routing (well, sort of :-)).


THE IMPORTANCE OF THE ROUTING TABLE

   The NET/ROM routing table is analogous to the IP routing table:  if
there is nothing in it, your NET/ROM traffic will not go out.  You must
either manually enter a list of routes (perhaps via your autoexec.net)
or wait to receive routing broadcasts from your neighbors before your
NET/ROM traffic will leave your station.

   If you go to send packets via NET/ROM and nothing happens, even if
you have trace mode on, make sure that the destination node is in your
NET/ROM routing table.  If sending IP traffic, double check the ARP table
for an appropriate NET/ROM ARP entry for the destination node (see below
for more information on the use of the ARP table).  The ARP table is not
used for NET/ROM transport routing.


INTERFACING WITH NET/ROMS USING YOUR SERIAL PORT

   What if you have a net/rom node or nodes, and you'd like to attach
them to your computer via their serial interfaces, and use net as a
packet switch?  It's very easy:  you have to attach those interfaces,
using the "attach asy" command, but specifying type "nrs" instead of
"slip" or "kiss".  "nrs" is the net/rom serial framing protocol, which
is like KISS, but uses different framing characters and has an 8-bit
checksum.

   When you attach an nrs interface, it can be used for passing IP
datagrams or AX.25 frames over serial lines or modems.  To use it
for net/rom, you have to identify it to the netrom code just like
any other interface, with the "netrom interface" command.


THE TIME TO LIVE INITIALIZER

   The "netrom ttl" command allows setting of the time-to-live
initializer for NET/ROM datagrams.  I recommend a value of 16
for most networks.  Use more if you expect to go more than 16 hops.
The default is 64.

   The purpose of the ttl initializer is to prevent a packet from
getting caught forever in routing loops.  Every router who handles
the packet decrements the ttl field of the network datagram before
sending it on, and when it reaches 0 it is discarded.


USING NET/ROM SUPPORT FOR IP

   Now you know all the commands, but how do we actually use net/rom
for IP communications?  This takes two steps:

   Step one:  update the routing table.  In all likelihood, you will
use net/rom to gateway two IP subnets.  So, you'll probably want to
identify a station on each end as a gateway.  Let's say we're on the
Milwaukee subnet, and we want to talk to someone in Madison.  If
we're not the gateway, we just have a routing table entry like this:

    route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr

This specifies that wg9ate should get all packets for the 44.92.0.x
subnet via interface ax0.

   Wg9ate has this routing table entry:

    route add [44.92.0.0]/24 netrom w9mad-pc.ampr

(presuming that w9mad is the Madison gateway).  Now, when the IP layer
at wg9ate gets datagrams for Madison, it knows that they have to go via
net/rom to w9mad.  Notice that we don't specify a "real" interface,
like ax1 or nr0, in the route entry.  The net/rom network layer will
pick the right interface based on its net/rom routing tables.

   We're not done yet, though.  w9mad-pc.ampr is not an ax.25
callsign.  The net/rom send routine called by the IP layer needs
to map from the IP address to an ax.25 address.  It does this via
a manually added arp entry:

    arp add w9mad-pc.ampr netrom w9mad

[We kind of fudged by using the arp table for this purpose, since
there is no way to do automatic address resolution for net/rom,
and arp messages are never sent or received for net/rom nodes.
However, the arp table does contain precisely what we have here:
mappings from IP addresses to callsigns, and it saved a lot of
code to do it this way.]

Notice also that no digipeaters are ever specified in the arp entry
for a net/rom node.  Also, the callsign to which we are mapping
is the final destination of the packet, not the non-destination
neighbor.  That neighbor will be picked based on the net/rom
routing tables.

   So, as a summary, let's look at what happens to a packet that
reaches the IP layer on wg9ate, destined for Madison.  The IP
routing code looks the destination IP address up in the table,
and discovers that it should go via net/rom to w9mad-pc.ampr.
So, it passes the packet to the net/rom send routine.  That
routine uses the arp table to translate w9mad-pc's IP address
to the callsign "w9mad".  Then it passes the packet to the
net/rom routing code.  That code checks to see if the destination
callsign (w9mad) is the same as that of any of its assigned
net/rom interfaces.  Since it isn't, it puts a network layer
header (a.k.a. net/rom level 3 header) on it, and looks for
w9mad in its routing tables.  Presumably, it finds an appropriate
neighbor for the packet, and sends in out via ax.25.  The net/rom
network does the job of actually getting the packet to its
destination.

   At w9mad, the packet's protocol ID causes it to be sent to
the same net/rom routing code that handled the outgoing packet
from wg9ate (running on a different computer, of course).  Now
the destination callsign matches, so the net/rom network layer
header is stripped off, and packet is passed up to the IP layer.
(Net/rom network headers don't have a protocol ID byte, so
we just hope for the best.  If a net/rom node addresses a
net/rom transport layer packet to us, it is likely to be dropped
by IP for any of a number of reasons.)


THE NET/ROM TRANSPORT LAYER

   NET/ROM transport is the protocol used by NET/ROM node to
communicate end-to-end.  When a user attaches to a NET/ROM
via AX.25, and asks for a connect to a node in the NODES list,
his local NET/ROM tries to open a transport connection to
the destination node over the NET/ROM network.  NET/ROM transport
packets are carried in NET/ROM network datagrams, just like
IP datagrams.

   You shouldn't use NET/ROM transport when connecting to other
TCP/IP stations.  TCP is a much better protocol than NET/ROM
transport, and makes better use of available bandwidth.  Also,
BM and SMTP are more convenient to use than a TCP/IP station's
mailbox facility.  However, for communicating with AX.25 users
via the NET/ROM network, the transport facilities in NET will
work better (and more easily) than the traditional method of
connecting to your local node via AX.25.


CONNECTING VIA NET/ROM TRANSPORT

   To connect to the node whose alias is FOO and whose callsign is
W9FOO, you can issue either of the following two commands:

    netrom connect foo

    netrom connect w9foo

If foo:w9foo is in your NET/ROM routing table, your station will
transmit a connect request to the appropriate neighbor used to
reach w9foo.

   NET/ROM transport sessions are very much like those for AX.25.
You can use the disconnect, reset, kick, upload, and record
commands, and the session command to switch sessions.


DISPLAYING THE STATUS OF NET/ROM CONNECTIONS

   The command

    netrom status

is used to display the status of all NET/ROM connections, which will
include those used in keyboard sessions as well as ones attached to
the mailbox.  For more detailed information on a session, you can
use the address of the NET/ROM control block:

    netrom status <&nrcb>

where <&nrcb> is the hex address given in the short form of the command
or in the "session" display.


NET/ROM TRANSPORT PARAMETERS

   The NET/ROM transport parameters may be set with the various
NET/ROM subcommands.  Their meanings are listed below:

    acktime:    This is the ack delay timer, similary to ax25 t2.
                The default is 3000 ms.

    choketime:    The time to wait before breaking a send choke condition.
                Choke is the term for NET/ROM flow control.

    irtt:        The initial round trip time guess, used for timer setting.

    qlimit:        The maximum length of the receive queue for chat sessions.
                This is similar to ax25 window.

    retries:    Maximum retries on connect, disconnect, and data frames.

    window:        Maximum sliding window size, negotiated down at connect
                time.


THE MAILBOX

   The AX.25 mailbox also accepts NET/ROM connections.  The "mbox on"
and "mbox off" commands control whether the mailbox is turned on for
NET/ROM as well as AX.25, and the "mbox" command displays current
mailbox connects of both types.

   Many people have observed that the AX.25 mailbox requires the user
to enter a carriage return to bring up the banner and prompt.  This is
because of certain defects of that protocol when it is used as the
link layer for several different higher level protocols, and is
unavoidable.  (So stop asking, OK? :-))  The NET/ROM mailbox does
not require the carriage return, and will be activated as soon as
the incoming connection is completed.


WHERE TO GO FOR MORE INFORMATION

   The paper "Transmission of IP Datagrams over NET/ROM Networks"
appeared in the Seventh ARRL Networking Conference papers, available
from the ARRL.  In it, I describe the more technical details of how
the NET/ROM network support works.

   If you want to learn about NET/ROM, talk your local NET/ROM or TheNET
operator out of his or her manual.  If you want to learn more, read
the source code.  That's about it for sources, since the NET/ROM
protocols originated in a commercial product.


ABOUT THE CODE

   There has been a great deal of controversy about TheNET, a no-charge
NET/ROM clone for TNCs.  This is not the place to discuss the truth
of the charges leveled by Software 2000 against its authors, but that
situation requires me to make the following statement:

   The NET/ROM transport support in NET.EXE was not taken in any way,
shape or form from NET/ROM (whose source I have never seen) or from
TheNET.  The protocol code is based on protocol 6 from Tanenbaum's
excellent book, Computer Networks, as a moderately careful reading
of both should show.  The source code is freely distributed, so
the curious reader should have the opportunity to check this assertion
if he or she so desires.

   The smoothed round trip time calculation, which is not done in
"real" NET/ROMs (and should be, by the way -- they'd work a whole
lot better) is adapted from that used by KA9Q in the TCP protocol
in NET.  The dicey business of adapting it to a sliding windows
protocol with selective retransmission was done by me, all alone,
after my cries for help on the tcp-group mailing list went unanswered
:-).

   I have taken the precaution of copyrighting the NET/ROM code in
NET.  It may be freely distributed for non-commercial purposes, in
whole or in part, and may be used in other software packages such
as BBS systems if so desired, so long as the copyright notice is
not removed from the source files, and the program in which it is
used displays "NET/ROM code copyright 1989 by Dan Frank, W9NK"
when it starts up.

   Any person who wishes to distribute the code, or anything based
on the code, for commercial purposes will find me very reasonable,
but rather insistent about being compensated for the hours I've
spent working on it.

---------------------- Enjoy!

   Dan Frank, W9NK ([e-mail], w9nk@w9wi-1 BBS, #MADIP:W9NK)